1. Technical Field
The present application relates generally to an improved data processing system and method. More specifically, the present application is directed to a system and method for developing Diameter applications.
2. Description of Related Art
The Diameter protocol is a relatively new protocol proposed by the Internet Engineering Task Force (IETF) for Authentication, Authorization, and Accounting (AAA) purposes. The Diameter protocol is a binary protocol that consists of a message header followed by attribute-value pairs. The header contains a field indicating the command code for the message and whether the message is a request or a response. The command code provides the context necessary to interpret the semantics of the attribute-value pairs within the message body. The Diameter protocol specification consists of a base protocol specification (RFC 3588 available at www.ietf.org/rfc/rfc3588.txt) and Diameter applications. The base protocol specifies a number of attribute-value pairs that are common to all Diameter applications. A Diameter application extends the base protocol by defining new commands and attribute-value pairs. These must be interpreted by the Diameter element logic accordingly.
The Diameter protocol is one of the fundamental protocols proposed for the IP-Multimedia Sub-system (IMS) architecture. The IMS architecture is a Third Generation Partnership Project (3GPP) standard architecture describing components that sit at the core infrastructure of a voice over internet protocol (VoIP) service provider (see www.3gpp.org for more information). The IMS architecture offers significant value to service providers since it allows them to introduce new real-time multimedia services and provide end users with a seamless experience across multiple access networks. Within IMS, Diameter operates on top of reliable transport protocols, such as the Transport Control Protocol (TCP).
FIG. 1 is an exemplary diagram of the architecture of the Diameter protocol stack. As shown in FIG. 1, the Diameter base protocol 130 lies on top of the TCP layer 120, which is above the IP layer 110. On top of the Diameter base protocol 130 are predefined interfaces 140 for IMS functionality. These interfaces 140 are common to all Diameter applications, which provide the Diameter extensions 150.
The Diameter base protocol 130 provides basic services including delivery of attribute-value pairs (AVPs), capability negotiation, error notification, accounting services, and extensibility via new command codes and AVPs. The IMS architecture defines several Diameter interfaces 140, between various IMS components. These interfaces extend the basic services of the Diameter base protocol 130 and provide support for authentication and authorization functions. Examples of such interfaces are the IMS Sh, Dh, Cx, Ro, Rf, and Dx interfaces, which are illustrated in FIG. 2 for an IMS architecture.
As shown in FIG. 2, the IMS architecture includes an Application Server (AS) 210, Call Session Control Functions (CSCF) which may be either an Interrogating CSCF (I-CSCF) 220 or a Service CSCF (S-CSCF) 230, a Home Subscriber Server (HSS) 240, and a Subscription Locator Function (SLF) 250. With reference to FIG. 2, the IMS “Sh” interface is an interface that provides a method of communication between a Session Initiation Protocol (SIP) Application Server (AS) 210 function and Home Subscriber Server (HSS) network elements 240, or between multiple IMS Application Servers 210. The “Sh” interface allows for download and update of transparent and non-transparent user data and request and send notifications on changes in the user data.
The IMS “Dh” interface is used between the AS 210 and the SLF 250. The “Dh” interface is used to get the address of the HSS 240 serving an IMS public user identity or public service identity. The “Dh” interface uses the same message set as the “Sh” interface.
The “Cx” interface operates between an I-CSCF 220 and the HSS 240 and between the S-CSCF 230 and the HSS 240. The “Cx” interface allows for location management procedures (exchange of location information), user data handling procedures (download user data stored in the server), and user authentication procedures. The HSS 240 implements the Diameter multimedia server side of the “Cx” interface while the I-CSCF 220 and the S-CSCF 230 implement the Diameter Multimedia client side of the “Cx” interface.
The “Dx” interface is used between the I-CSCF 220 and the S-CSCF 230, and the SLF 250. The “Dx” interface is used to get the address of the HSS 240 serving an IMS Public User Identity or Public Service Identity. The “Dx” interface uses the same message set as the “Cx” interface.
For charging, the 3GPP defines two types of interfaces. The online charging interface “Ro” is used for real-time billing while a service is occurring. Charging information can affect the service being rendered. The offline charging interface “Rf” is used to transfer charging information that will not affect, in real-time, the service being rendered. The “Ro” interface is based on the IETF defined Credit Control Application (RFC 4006). The “Ro” interface uses the Credit-Control command (CCR/CCA). The “Rf” interface is based on the accounting functionality of IETF-Diameter base (RFC 3588) and uses the accounting command (ACR/ACA). Other interfaces may also be provided as common interfaces that extend the Diameter base protocol but which are common to all Diameter applications.
Another core protocol of the IMS architecture is the Session Initiation Protocol (SIP) which is a signaling protocol used to setup multimedia sessions. The SIP programming model for the J2EE application server environment consists of a SIP servlet container. Applications are structured as servlet logic with lower-level communication being handled by the SIP container. Various RFCs and specifications cover SIP, RFC 3261 covers the SIP base protocol, RFC 3262 covers the SIP PRACK extension, FRC 3265 covers SIP event notification, and JSR 116 is the SIP servlet specification.
As mentioned above, the Diameter protocol stack is built upon IP and TCP layers of communication. The HyperText Transfer Protocol (HTTP) is one of the base transport protocols for the Internet. A typical programming model for handling Internet requests is via the HTTP servlet programming model. RFC 2616 covers the HTTP v1.1 protocol.
Many IMS-based applications require HTTP, SIP, and Diameter capabilities for completeness. For example, a conferencing application may provide an HTTP-based “view” of conference participants, SIP may provide the voice signaling required, and Diameter may be used to record chargeable events using the Ro interface. Currently, HTTP and SIP logic can be written using Java Servlet technologies within a converged HTTP/SIP servlet container, e.g., see WebSphere Application Server 6.1. Diameter application logic, however, currently cannot be written using Java Servlet techniques. Thus, Diameter application logic cannot leverage traditional Java Servlet strengths such as high availability, flexible request dispatching, application packaging, application tooling, application deployment, load balancing, and converged session affinity in a clustered environment.